Add sha256 checksums to the lockfile
authorAlex Crichton <alex@alexcrichton.com>
Wed, 3 Feb 2016 19:04:07 +0000 (11:04 -0800)
committerAlex Crichton <alex@alexcrichton.com>
Mon, 1 Aug 2016 17:14:52 +0000 (10:14 -0700)
commit5430db61f6c2668ec94945c91a1df22015ff1cf8
treedfe128b3e27488c0e324fe7384f501339124d86f
parent8214bb953dee7f529747ce69ff81fe294259a6a0
Add sha256 checksums to the lockfile

This commit changes how lock files are encoded by checksums for each package in
the lockfile to the `[metadata]` section. The previous commit implemented the
ability to redirect sources, but the core assumption there was that a package
coming from two different locations was always the same. An inevitable case,
however, is that a source gets corrupted or, worse, ships a modified version of
a crate to introduce instability between two "mirrors".

The purpose of adding checksums will be to resolve this discrepancy. Each crate
coming from crates.io will now record its sha256 checksum in the lock file. When
a lock file already exists, the new checksum for a crate will be checked against
it, and if they differ compilation will be aborted. Currently only registry
crates will have sha256 checksums listed, all other sources do not have
checksums at this time.

The astute may notice that if the lock file format is changing, then a lock file
generated by a newer Cargo might be mangled by an older Cargo. In anticipation
of this, however, all Cargo versions published support a `[metadata]` section of
the lock file which is transparently carried forward if encountered. This means
that older Cargos compiling with a newer lock file will not verify checksums in
the lock file, but they will carry forward the checksum information and prevent
it from being removed.

There are, however, a few situations where problems may still arise:

1. If an older Cargo takes a newer lockfile (with checksums) and updates it with
   a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then
   the `[metadata]` section will not be updated appropriately. This modification
   would require a newer Cargo to come in and update the checksums for such a
   modification.

2. Today Cargo can only calculate checksums for registry sources, but we may
   eventually want to support other sources like git (or just straight-up path
   sources). If future Cargo implements support for this sort of checksum, then
   it's the same problem as above where older Cargos will not know how to keep
   the checksum in sync
src/cargo/core/registry.rs
src/cargo/core/resolver/encode.rs
src/cargo/core/resolver/mod.rs
src/cargo/core/summary.rs
src/cargo/ops/resolve.rs
src/cargo/sources/config.rs
src/cargo/sources/registry.rs
tests/cargotest/support/registry.rs
tests/lockfile-compat.rs [new file with mode: 0644]
tests/registry.rs